This chapter will provide information on the background of this invention proposal. The first part of this chapter is concerned with the technical field of this invention proposal in general. After that the initial problem is described. Finally, the residual problem is addressed, which consequently provides the motivation for this invention proposal.
1. Technical Field
Today's IT infrastructures are composed of a large number of heterogeneous, distributed stateful resources. That is, complex multi-tier applications typically comprise or are hosted by several heterogeneous IT resources (e.g. servers, operating systems on those servers, databases, application server software, etc.). For each of those resources several resource-specific management functions are available for controlling the operation of a resource, i.e. for creating (provisioning), destroying (de-provisioning) and controlling the operation and configuration of a stateful resource. Resource management functions of a resource may also control other stateful resources—for example, a resource that acts as a resource manager may offer a service to create/provision a new instance of a certain other resource.
With regard to the notion of “Systems Management Flows” we also use the term “systems management tasks” for resource management functions (see the concurrently filed application cross-referenced above).
In order to perform systems management in the scope of a whole IT system (in contrast to single resources), an integration of single systems management tasks (for specific resources) into a systems-wide Systems Management Flow is necessary in order to treat a system as a whole and keep it in a consistent state.
The key to managing heterogeneous, distributed IT resources in an efficient and consistent way is to have common, standards-based interfaces to IT resources. In particular, the single systems management tasks providing management access to resources have to be accessible using common, standards-based interfaces. A common way for accessing distributed resources is using stateful Web services interfaces. This issue is addressed by several open Web Services standards (such as the Web Services Resource Framework (WS-RF), Web Services Distributed Management (WSDM), WS-Transfer, WS-Enumeration, etc.). Consequently, within the scope of this document it is assumed that systems management tasks for managing IT resources provide a stateful Web services interface and can thus be accessed by a management system in a uniform way.
The modeling of relationships between resources is another important aspect for managing heterogeneous distributed IT resources. For example, a resource may use or host another resource. Relationships between stateful resources are covered by open standards like WSDM.
Initial Problem
EP 1636743A1 describes an approach for the proper instantiation, modification, and configuration of resource graphs representing complex multi-tier applications by using so-called order documents. Order documents are XML documents, which are tailored to the area of resource graph operations—with special focus on the comfortable modification of existing resource topologies. Although order documents have the advantage of comfortable means in the systems management area, there is the disadvantage that there is a special runtime environment needed in order to process these order documents. Since the processing of order documents has pretty much the character of traditional workflow processing, it would be desirable to process the semantics expressed by the order document in combination with the existing resource topology that is to be modified, in a standard workflow container (e.g. the IBM WebSphere Process Server being able to process Business Process Execution Language (BPEL) compliant process definitions). This would help to avoid the duplicate implementation of typical qualities of services for such runtime environments (e.g. security, error handling, scalability, etc.).
2. Prior Art
Traditionally, the provisioning of resources is supported by dedicated provisioning products. These software applications normally define their view of the data center within a database. This database is normally populated by some discovery mechanisms. Based on the information, which is stored in the database, another component of the provisioning product, a deployment engine, drives provisioning workflows in order to change the data center infrastructure as desired by the administrator. An example for such a provisioning product is IBM's Tivoli Provisioning Manager (TPM). Although TPM uses its own (proprietary) workflow description today, it could also be envisioned that there is some industry-standards based workflow description language used, like for example the Business Process Execution Language (BPEL).
Residual Problem
Each of the technologies described in the previous section have certain drawbacks, which will be elaborated in the following.
The traditional approach of “workflow-driven systems management” (as it is today for example available via IBM's Tivoli Provisioning Manager) has the drawback that the used workflows are very inflexible, i.e. each time the desired deployment topology changes (e.g. for a multi-tier application from single-node deployment to distributed deployment), the workflows have to be adapted as well. This is due to the fact that the workflows assume a certain resource topology underneath. Once this resource topology changes slightly, the workflows break. As already indicated in the previous chapter, this kind of drawback is not limited to a specific product. This kind of drawback applies to all approaches being based on the concept of performing systems management actions by using plain activity-based workflow technology.
The concept of orders overcomes the aforementioned drawback of the strong dependency of the description for systems management actions on underlying resource topology. This is achieved by combining the knowledge about the information required by resources with the knowledge about the actual resource topology. The drawback of this approach is in turn that it is not possible to leverage existing products supporting traditional workflows. That means, it would be required to build the kind of tooling that is today for example available in the BPEL area (Process Modeling Tools, Debugging Tools, etc.) again for order documents. Furthermore, it would be required a special runtime infrastructure for order documents with all the qualities of service, which are today already available in standard process engines (e.g. IBM WebSphere Process Server). These qualities of service refer to security, scalability, error recovery, transactional behavior, etc.
So the residual problem in this area is the problem of needing a combination of the flexibility of order documents and the robustness and industry support of standardized workflow languages. Therefore, this patent describes an approach for transforming order documents, which can be regarded as very dynamic interpreter-based workflows into static, activity-based processes, like for example BPEL processes. This allows being very flexible in terms of the description of systems management actions while using enterprise-level tooling and runtime support.